OH2022 - Patient Portal
Status | DONE |
|---|---|
Impact | Medium |
Driver | @Alessandro Domanico |
Approver | @Claudio Rosazza |
Contributors | @Alessandro Domanico @miz |
Informed | @Ilario Gavioli @Alberto Mandelli |
Due date | Jun 30, 2022 |
Resources | https://docs.google.com/document/d/1IYKXg1zR2X13ooufRXYxp7tTDkf1_9aEDwUQOiiPzxE/edit?usp=sharing document |
Relevant data
The goal is to develop an extension of Open Hospital, initially as an independent project, a Patient Portal usable via web / mobile devices to improve the quality and accessibility of health and hospital services, creating an affordable solution for small facilities in LICs.
Putting the patient at the center allowing him to consult his/her own data remotely and enables the possibility of interaction with the health facility for visits, checks, deadlines, use of drugs.
Background
The context is the one of medium-small rural hospitals in LICs, with scarce connectivity and resources, where however the access and the use of apps and Internet has grown considerably in the last decade, as well as the spread of low-cost smartphones that are able to already access online payments platforms and national services.
However, it is unlikely that a structure in this context will have its own online server (with a public IP) so we need to think about a cloud-native solution that can be easily installed on site (initially being tested in LAN) and, more probably, on cloud servers. It’s database must be populated with data in one-way direction by the healthcare facility.
It is therefore important that the portal is independent and configurable, and that it offers the maximum possible robustness with the state of the art of existing technologies for users, for the data it will host and that must be accessible in maximum security for privacy. Yet it should include an in-built telemetry system in order to measure its usage.
To do so, there are several different technologies on the market, and we need to choose wisely the most valuable in terms of popularity, diffusion, effectiveness, security, robustness, etc…
📱 Use cases
Patient A connects to the portal, logs in with his/her Google account, is immediately presented with his/her personal data with the data recorded in the PATIENT table and his dossier, checks the list of appointments
Patient B connects to the portal as soon as he/she leaves the hospital to check his/her medical prescription and therapy; he/she leave feedback on the visit
Patient C connects to the portal, from home, to check the doctor's instructions on his/her visit and the diagnosis that has been given; takes the opportunity to read the related multimedia contents, offered directly on the portal or with external links (e.g. Wikipedia, SNOMED, etc…)
👨🏫 Required features
Authentication Layer (usr:pwd, oauth, 2FA, SMS)
Multi User
Multi Language
Responsive UX
ORM
OpenSource License
Options considered
| Option 1 | Option 2 | Option 3 |
|---|---|---|---|
Description | Replicate Open Hospital structure | Start by existing frameworks | Customize existing softwares |
Pros and cons | Same as Open Hospital, in the future the two projects could be easily merged Homogeneity, same community can contribute to the project Building a project from scratch can be overwhelming | Many feature already built-in Fast development Different languages (like Python) would require a new skills in the community Special features may need the framework itself customization | Some features granted by the software itself Security and state of the art updates granted by the software’s community itself Focusing on the final results without caring too much about the structure Customizations need to master how the software works internally Strong binding to an existing software can be risky |
Estimated cost | SMALL | MEDIUM | Large |
Action items
Outcome
Option 1: in order to leverage the actual community know-how and to reutilize part of the current “ui” components
Open Hospital powered by ISF
2005 - 2016 ISF © Informatici senza frontiere - ONLUS